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Generic Routing Encapsulation (GRE) 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 


This document specifies a protocol for encapsulation of an arbitrary 
network layer protocol over another arbitrary network layer protocol. 


1. Introduction 


A number of different proposals [RFC1234, RFC1226] currently exist 
for the encapsulation of one protocol over another protocol. Other 
types of encapsulations [RFC1241, RFC1479] have been proposed for 
transporting IP over IP for policy purposes. This memo describes a 
protocol which is very similar to, but is more general than, the 
above proposals. In attempting to be more general, many protocol 
specific nuances have been ignored. The result is that this proposal 
may be less suitable for a situation where a specific "X over Y" 
encapsulation has been described. It is the attempt of this protocol 
to provide a simple, general purpose mechanism which reduces the 
problem of encapsulation from its current O(n^2) size to a more 
manageable size. This memo purposely does not address the issue of 
when a packet should be encapsulated. This memo acknowledges, but 
does not address problems such as mutual encapsulation [RFC1326]. 
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In the most general case, a system has a packet that needs to be 
encapsulated and delivered to some destination. We will call this 
the payload packet. The payload is first encapsulated in a GRE 
packet. The resulting GRE packet can then be encapsulated in some 
other protocol and then forwarded. We will call this outer protocol 
the delivery protocol. The algorithms for processing this packet are 
discussed later. 


Finally this specification describes the intersection of GRE 
currently deployed by multiple vendors. 


The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined 
in RFC 2119 [RFC2119]. 


2. Structure of a GRE Encapsulated Packet 


A GRE encapsulated packet has the form: 


This specification is generally concerned with the structure of the 
GRE header, although special consideration is given to some of the 
issues surrounding IPv4 payloads. 

2.1. GRE Header 


The GRE packet header has the form: 


0 GL:IZ 3,4 5.00.0589 0 12 3.4 5 6 7.8.9.0 172-3 4 5 6 $» 8 9 0 tT 
*—R—4—4—4-4-t-t-t-----t-t-t-t-t-—t-—t-L-4— 4 —4—4—4-—4-4-4-4-4-4 
[c] Reserved0 | Ver | Protocol Type 
f=tF=#2#=#=#-=#H-+=F=+=#=#<=#=+>4+=4<=$=4+=#24F=#=+=#=4=#=4+>$=4X=#=4+=f#=4$<=+ 
| Checksum (optional) | Reservedl (Optional) 
T—R—R—4-—4-4-—t-t-t-----t-t-t-t-t-t-—t-L-4— 4 —4—4-4-4-4-4-4-4-4 
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2.2. Checksum Present (bit 0) 


If the Checksum Present bit is set to one, then the Checksum and the 
Reservedl fields are present and the Checksum field contains valid 
information. Note that a compliant implementation MUST accept and 
process this field. 


2.3. ReservedO (bits 1-12) 


A receiver MUST discard a packet where any of bits 1-5 are non-zero, 
unless that receiver implements RFC 1701. Bits 6-12 are reserved for 
future use. These bits MUST be sent as zero and MUST be ignored on 
receipt. 


2.3.1. Version Number (bits 13-15) 
The Version Number field MUST contain the value zero. 

2.4. Protocol Type (2 octets) 
The Protocol Type field contains the protocol type of the payload 
packet. These Protocol Types are defined in [RFC1700] as "ETHER 
TYPES" and in [ETYPES]. An implementation receiving a packet 


containing a Protocol Type which is not listed in [RFC1700] or 
[ETYPES] SHOULD discard the packet. 


2.5. Checksum (2 octets) 


The Checksum field contains the IP (one's complement) checksum sum of 
the all the 16 bit words in the GRE header and the payload packet. 
For purposes of computing the checksum, the value of the checksum 
field is zero. This field is present only if the Checksum Present bit 
is set to one. 


2.6. Reservedl (2 octets) 


The Reservedl field is reserved for future use, and if present, MUST 
be transmitted as zero. The Reservedl field is present only when the 
Checksum field is present (that is, Checksum Present bit is set to 
one). 


3. IPv4 as a Payload 


When IPv4 is being carried as the GRE payload, the Protocol Type 
field MUST be set to 0x800. 
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3.1. Forwarding Decapsulated IPv4 Payload Packets 


When a tunnel endpoint decapsulates a GRE packet which has an IPv4 
packet as the payload, the destination address in the IPv4 payload 
packet header MUST be used to forward the packet and the TTL of the 
payload packet MUST be decremented. Care should be taken when 
forwarding such a packet, since if the destination address of the 
payload packet is the encapsulator of the packet (i.e., the other end 
of the tunnel), looping can occur. In this case, the packet MUST be 
discarded. 


4. IPv4 as a Delivery Protocol 


The IPv4 protocol 47 [RFC1700] is used when GRE packets are 
enapsulated in IPv4. See [RFC1122] for requirements relating to the 
delivery of packets over IPv4 networks. 


5. Interoperation with RFC 1701 Compliant Implementations 


In RFC 1701, the field described here as ReservedO contained a number 
of flag bits which this specification deprecates. In particular, the 
Routing Present, Key Present, Sequence Number Present, and Strict 
Source Route bits have been deprecated, along with the Recursion 
Control field. As a result, the GRE header will never contain the 
Key, Sequence Number or Routing fields specified in RFC 1701. 


There are, however, existing implementations of RFC 1701. The 
following sections describe correct interoperation with such 
implementations. 


5.1. RFC 1701 Compliant Receiver 


An implementation complying to this specification will transmit the 
ReservedO0 field set to zero. An RFC 1701 compliant receiver will 
interpret this as having the Routing Present, Key Present, Sequence 
Number Present, and Strict Source Route bits set to zero, and will 
not expect the RFC 1701 Key, Sequence Number or Routing fields to be 
present. 


5.2. RFC 1701 Compliant Transmitter 


An RFC 1701 transmitter may set any of the Routing Present, Key 
Present, Sequence Number Present, and Strict Source Route bits set to 
one, and thus may transmit the RFC 1701 Key, Sequence Number or 
Routing fields in the GRE header. As stated in Section 5.3, a packet 
with non-zero bits in any of bits 1-5 MUST be discarded unless the 
receiver implements RFC 1701. 
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6. Security Considerations 


Security in a network using GRE should be relatively similar to 
security in a normal IPv4 network, as routing using GRE follows the 
same routing that IPv4 uses natively. Route filtering will remain 
unchanged. However packet filtering requires either that a firewall 
look inside the GRE packet or that the filtering is done on the GRE 
tunnel endpoints. In those environments in which this is considered 
to be a security issue it may be desirable to terminate the tunnel at 
the firewall. 


7. IANA Considerations 


This section considers the assignment of additional GRE Version 
Numbers and Protocol Types. 


7.1. GRE Version Numbers 
This document specifies GRE version number 0. GRE version number 1 is 
used by PPTP [RFC2637]. Additional GRE version numbers are assigned 
by IETF Consensus as defined in RFC 2434 [RFC2434]. 

7.2. Protocol Types 


GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES are 
assigned by Xerox Systems Institute [RFC1700]. 
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9. Appendix -- Known Issues 


This document specifies the behavior of currently deployed GRE 
implementations. As such, it does not attempt to address the 


following known issues 


o Interaction Path MTU Discovery (PMTU) [RFC1191] 


Existing implementations of GRE, when using IPv4 as the Delivery 
Header, do not implement Path MTU discovery and do not set the 
Don't Fragment bit in the Delivery Header. This can cause large 
packets to become fragmented within the tunnel and reassembled at 
the tunnel exit (independent of whether the payload packet is using 
PMTU). If a tunnel entry point were to use Path MTU discovery, 


however, that tunnel 


entry point would also need to relay ICMP 


unreachable error messages (in particular the "fragmentation needed 
and DF set" code) back to the originator of the packet, which is 


not a requirement in 
Path MTU information 


this specification. Failure to properly relay 
to an originator can result in the following 


behavior: the originator sets the don't fragment bit, the packet 
gets dropped within the tunnel, but since the originator doesn't 
receive proper feedback, it retransmits with the same PMTU, causing 
subsequently transmitted packets to be dropped. 


o IPv6 as Delivery and/or Payload Protocol 


This specification describes the intersection of GRE currently 


deployed by multiple 


vendors. IPv6 as delivery and/or payload 


protocol is not included in the currently deployed versions of GRE. 


o Interaction with ICMP 


o Interaction with the 
o Multiple and Looping 
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12. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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